home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 941 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.5 KB
  1. From: Philippe Verdy <100105.3120@compuserve.com>
  2. Message-ID: <4jsf81$t2m@dub-news-svc-3.compuserve.com>
  3. X-Original-Date: 3 Apr 1996 00:03:04 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 03 Apr 96 03:10:47 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: static members as members of a metaclass h
  9. Organization: CompuServe Incorporated
  10. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  11.     iQBFAgUBMWHsW+EDnX0m9pzZAQGX4QF/RoYSA2z9/X0+VPtKThGwCefFuuSwqG61
  12.     SYdFugTce9PRPLGCpIieglHTcp1m6kxV
  13.     =4ejg
  14.  
  15. kanze@gabi-soft.fr (J. Kanze) s'icrit :
  16. > In article <4jckdc$ad6@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
  17. > Clamage) writes:
  18. > 
  19. >     [...]
  20. > |> I believe a reasonable solution to the problem of initialization of
  21. > |> non-local static data is not to use non-local static data!
  22. > 
  23. > |> Instead of a static data object or static class data member, use a 
  24. > |> function with a local static object.
  25. >     [...]
  26. > |> Only two features are missing, compared to non-local static objects:
  27. > 
  28. > |> 1. If you never reference an object, it is never initialized.
  29. > 
  30. > But is this guaranteed by the standard anyway?  I know that I have a
  31. > significant number of static objects which must be initialized before
  32. > main (but in any order), but I have always believed that this works
  33. > because of the way current compilers work, and not because of anything
  34. > in the standard.
  35. > 
  36. > |> 2. The order of destruction remains unspecified. If that is a problem,
  37. > |> possibly the static objects could be of a type which has a do-nothing
  38. > |> destructor and a "destroy" member function which could be called
  39. > |> explicitly at the proper time.
  40. > 
  41. > I thought that the order of destruction was the reverse of
  42. > initialization.  This is what it says in the January draft, at least.
  43. > Has this been changed?
  44.  
  45. I think that the order of destruction of static objects is
  46. unspecified, only because the order of construction is unspe-
  47. cified.
  48.  
  49. Which ever order the compiler chooses, the order of destruction
  50. of the same static objects MUST be the exact opposite of their
  51. construction order ! This is compiler-dependent.
  52.  
  53. I suggest the standard allows for static class constructors to
  54. remove this compiler dependence !
  55. ---
  56. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  57. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  58. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  59. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  60. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  61.